home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-10 < prev    next >
Text File  |  1988-12-01  |  10KB  |  225 lines
  1. IEN # 10                                           William W. Plummer
  2. Supercedes: None                                                  BBN
  3. Replaces: None                                           7 March 1977
  4.  
  5. Section: 2.2.4.1
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.         Internet Broadcast Protocols
  14.  
  15.  
  16.  
  17.             William W. Plummer
  18.  
  19.         Bolt Beranek and Newman, Inc.
  20.             50 Moulton Street
  21.           Cambridge, Mass.  02173
  22.  
  23.  
  24.             7 March 77
  25.  
  26. Internet Broadcast Protocols                Plummer, 7MAR77
  27.  
  28.  
  29. 1.    The Applications
  30.  
  31.     At least two applications of a broadcast mechanism have come
  32. into view: a "news wire" service, where error-free delivery is required,
  33. and a "network speech" protocol where a small percentage of dropped or
  34. corrupted messages is permitted.  TCP is applicable to the former since
  35. it is designed to provide highly reliable connections, perhaps with some
  36. penalty in time.  To use TCP for network speech however, would required
  37. adding features specifically to defeat parts of the protocol.
  38.  
  39.     The question of using a modified TCP for speech-type applications
  40. will be deferred for further study.  TCP does provide some useful
  41. features (reliable establishment of connections, a way of naming connections,
  42. ability to reset half-open connections, etc.) which would be required in
  43. any application, but the issues which surface when partial reliability
  44. is permitted are complex.
  45.  
  46.     TCP is a good choice for the "news wire" application.  Here, a
  47. receiver may "tune in" to a source of reports and while he is connected,
  48. will receive continuous, error-free delivery.  In the following a
  49. mechanism for doing this will be proposed.
  50.  
  51.  
  52.  
  53. 2.    An Assumption and its Consequences
  54.  
  55.     A fundamental assumption of internet protocols (not only TCP) is
  56. that no special requirements may be placed on the participating networks.
  57. All they must be able to do is deliver a minimum sized packet with some
  58. semblance of reliability (Packet Radio Network is designed about a 10
  59. percent loss rate).  Various networks such as Packet Radio and Packet
  60. Satellite are fundamentally broadcast in nature and it would seem
  61. that some advantage of this could be taken.  However, to rely on these
  62. properties in order to make a broadcast mechanism work would imply
  63. retrofitting wired, single receiver networks such as the ARPANET so that
  64. their subnets had similar features.  This would violate the above stated
  65. assumption about internetting.
  66.  
  67.     Having to cope with single-receiver subnets suggests two ways to
  68. implement broadcasting.  One is the "read-this-and-pass-it-on" arrangement,
  69. and the other uses one or more distribution agents ("distributors").
  70.  
  71. The former solution has a major flaw in that service to all
  72. receivers will be interrupted should any host, intermediate network,
  73. or gateway fail, because acknowledgments from the last host cannot
  74. be returned to the broadcast source.  This is just too fragile; the
  75. distributor concept offers much better reliability.
  76.  
  77. Internet Broadcast Protocols                Plummer, 7MAR77
  78.  
  79.  
  80. 3.    Distributor
  81.  
  82.     Building a distributor involves writing a distribution server
  83. program which implements a layer of protocol not only above the subnet,
  84. but above TCP!  This a is highly desirable property since it separates
  85. the connection maintenance function from the broadcast function.
  86.  
  87.     A distribution server operates as follows:  It "listens" for
  88. a connection from anyone wishing to initiate a broadcast.  Once this
  89. connection has become bound, the broadcast source supplies a distribution
  90. list (exact form and content will be described later).  If all goes well,
  91. the distribution server will respond with the name of a specific
  92. input connection to itself to be used by the broadcasting process.
  93. The distribution server then establishes as may secondary connections
  94. as it sees fit -- some of which may go to other distributors in the same
  95. or different networks.
  96.  
  97.     The process run by the distributor for each specific connection
  98. simply reads a message from the broadcast source over the input connection
  99. and sends it out over each of the output connections.  As previously
  100. mentioned, some of the output connections will be directly to specific
  101. receivers, but others will be to secondary distributors.  In order to
  102. prevent hang-ups, it is required that each output connection address a
  103. set of receivers which is more specific than the input distribution
  104. list.  Thus it would be improper for a distribution server to accept
  105. an input list of "Net 3, all hosts" and open two output connections,
  106. one to "Net 3, Host 100" and the other to a distributor for the purpose
  107. of broadcasting to "Net 3, all hosts".  This secondary distribution
  108. list is not more specific than the input list and results in
  109. "Net 3, Host 100" being covered twice, most likely resulting in a
  110. hang-up if only one process is receiving the broadcast.
  111.  
  112.  
  113. 4.    Connection Closing and Errors
  114.  
  115.     Connections out of a distributor may be closed at any time
  116. by the receiver.  When all of the output connections have closed, the
  117. distributor will close its input connection.  Retransmission timeouts
  118. are to be treated as connection closings if they address a specific
  119. receiving process.  On the other hand a timeout on an output connection
  120. to a secondary distributor might be handled by attempting to reestablish
  121. communications via some different distributor, or if resources permit,
  122. to make specific output connections to each of the intended receivers.
  123.  
  124. Internet Broadcast Protocols                Plummer, 7MAR77
  125.  
  126.  
  127.  
  128. 5.    Flow Control
  129.  
  130.     Flow is governed by the window announced by the distributor to
  131. the broadcaster.  This window is a reflection of the amount of buffer
  132. space available in the distribution server itself, which in turn is
  133. a function of the number of output connections and the amount of
  134. unacknowledged information of each of these.  This automatically
  135. provides a safeguard against any particular output connection tying
  136. up buffer space in the distributor by telling the distributor that
  137. it is able to receive a vast amount of data and then being very slow
  138. at processing it -- this situation cannot arise because the distributor
  139. will not send anymore than it has received, and it will not have received
  140. much if its buffer space is committed to waiting for ACK for packets
  141. on slow output connections.
  142.  
  143.  
  144.  
  145. 6.    Resynchronization, etc.
  146.  
  147.     Resynchronization, sending ARQs, letter size management, and
  148. segment reassembly are handled inside the distributor, transparently
  149. to the broadcaster.  Only connection opening and closing, and data
  150. acknowledgement involve any communications back to the broadcaster.
  151.  
  152.  
  153.  
  154. 7.    Multiple Distributors and the Billboard
  155.  
  156.     Any host should be able to run a distribution server and a
  157. potential broadcaster could select any one that he can contact.  Which
  158. one(s) will be dictated by other, outside constraints such as privacy,
  159. accounting, etc.  On the other hand a potential receiver may want to
  160. find out where a good, relatively local source of some type of broadcast
  161. information is -- say weather information, but not airline flight
  162. information.  To handle this need, each distribution list
  163. will contain a title.  Upon setting up an instance of the distribution
  164. function, the title from the distribution list will be copied into
  165. a server-wide table along with the name of a local listening connection
  166. which is intended to service new output connections.
  167.  
  168.     In addition to the normal listening connection for new distribution
  169. lists, the distributor will maintain a listening connection for its
  170. billboard function.  This will be on a well-known socket.  A potential
  171. receiver looking for a specific kind of broadcast would do it by
  172. polling the distributors that it knows about, establishing a connection
  173. to the billboard function on each, and looking at what is listed to
  174. see if the desired information is being broadcast at that moment.
  175.  
  176. Internet Broadcast Protocols                Plummer, 7MAR77
  177.  
  178.  
  179.  
  180. If so, the distributor (output) socket listed will be used to tap
  181. the information.  Should the broadcast cease before the data connection
  182. is established, it is desirable to have the data connection attempt fail.
  183. However, it must also be the case that establishing the data connection
  184. does not pick up a newer instance of a distribution list.  So, some
  185. simple additional protocol is needed to resolve this issue.  This most
  186. likely will take the form of verifying the data connection attempt
  187. on the basis of a random key passed out by the billboard function.
  188.  
  189.  
  190.  
  191. 8.    Knowing Distributor Addresses
  192.  
  193.     The problem of knowing the identity (Network, Host) where
  194. distribution servers are running is common to both potential receivers
  195. and potential broadcast senders.  This problem is not peculiar to
  196. to the broadcast mechanism; it is the same one as a user faces when
  197. he want to use a FORTRAN system on some (i.e., any) host.  A master
  198. service directory must be consulted.  This could be a printed list
  199. like a telephone book or it could be implemented by a program, but
  200. it not a problem to be solved by the broadcast mechanism.
  201.  
  202.  
  203.  
  204. 9.    Controlled Unreliability
  205.  
  206.     Although it is felt that TCP is not well suited for the net speech
  207. type of service, there are a few considerations which might make this
  208. possible.  First, the broadcast source can "clear the pipe" at any time
  209. by sending a TCP level interrupt (INT) which forces all receivers to
  210. flush their current receive buffers.  The broadcaster would do this if
  211. the rate of delivery had dropped below some predetermined rate.  Notice
  212. that if the rate had gotten slow due to some host in the tree of
  213. distributors and receivers having crashed, then the INT will not be
  214. acknowledged, the distributor before the failed host will suffer a
  215. retransmission failure on the INT, and will mark that output connection
  216. as closed.  This has the overall effect of causing a momentary loss of
  217. data to many (if not all) receivers, but permanently removes the slow
  218. or crashed receiver from the distribution.
  219.  
  220.     Another possiblity is that acknowledgements could be faked
  221. either by the sources TCP or by distributors.  The problems involved
  222. are that control bytes can never by covered by fake ACKs, and that
  223. window information must be carefully handled.
  224.  
  225.